# 前端性能监控
2019.02.24
前端性能监控分为两种方式，一种叫做合成监控（Synthetic Monitoring，SYN），另一种是真实用户监控（Real User Monitoring，RUM）。
# 合成监控
什么叫合成监控？就是在一个模拟场景里，去提交一个需要做性能审计的页面，通过一系列的工具、规则去运行你的页面，提取一些性能指标，得出一个审计报告。
常见的工具有 Google 的 Lighthouse，webpagetest，pagespeed 等。
当然其实业界对于 Lighthouse 也是评价有褒有贬，因为 Google 借助这个看似中立的性能评审工具也是在推行它的一些技术的方案。 比如你的页面如果没有支持 PWA 评分就不会很高。
- 合成监控的优缺点
| 优点 | 缺点 |
|---|---|
| 实现简单 | 无法还原全部真实场景 |
| 能采集到丰富的数据，如硬件指标或瀑布图 | 登录等场景需要额外解决 |
| 不影响真实用户的访问性能 | 单次数据不够稳定 |
| 可以提供页面加载幻灯片等可视化分析途径 | 数据量较小，无法发挥更大价值 |
# 真实用户监控
所谓真实用户监控，就是用户在我们的页面访问之后就会产生各种各样的性能指标，之后会将这些性能指标上传的我们的日志服务器上，进行数据的提起清洗加工，最后在我们的监控平台上进行展示和分析的一个过程。
- 真实用户监控的优缺点
| 优点 | 缺点 |
|---|---|
| 无需配置模拟条件，完全还原真实场景 | 一定程度影响真实用户的访问性能及流量消耗 |
| 不存在登录等需要额外解决的场景 | 无法采集硬件相关指标 |
| 数据样本足够庞大，可以减少统计误差 | 受传输限制无法采集完整的资源加载瀑布图 |
| 新年数据可与其它数据关联，产生更大价值 | 无法可视化展示加载过程 |
# 对比
| 对比项 | 合成监控 | 真实用户监控 |
|---|---|---|
| 实现难度及成本 | 较低 | 较高 |
| 采集数据丰富度 | 丰富 | 基础 |
| 数据样本量 | 较小 | 大(视业务体量) |
| 适合场景 | 团队自由业务，对性能做定性分析，或配合 CI 做小数据量的监控分析 | 作为中台产品支持前台业务，对性能做定量分析，结合业务数据进行深度挖掘 |
# 方案
在真实用户性能数据采集时，要关注四个方面的东西：
使用标准的 API
定义合适的指标
采集正确的数据
上报关联的维度
# 使用标准的 API
之前大家都使用一个叫 performance.timing，来做性能监控。但这个 API 已经“废弃”了。为什么会被废弃？因为 W3C 给我们提供了更全面、更强大的一个性能分析矩阵，比单一的 performance.timing 更加强大，能帮助我们从各个方面分析前端页面性能。
采集性能数据时先抹平 Navigation Timing spec 差异，优先使用 PerformanceTimeline API(在复杂场景，亦可考虑优先使用 PerformanceObserver)。
# 定义合适的指标
First Meaningful Paint，首次有效渲染时长，这个指标最早是由 Google 提出的，它的一个核心的想法是渲染并不一定代表着用户看到了主要内容，Load 也不一定代表用户看到主要内容，那用户什么时候能够看到主要内容呢？我们假设当一个网页的 DOM 结构发生剧烈的变化的时候，就是这个网页主要内容出现的时候，那么在这样的一个时间点上，就是用户看到主要内容的一个时间点。
它的优点是相对校准的估算出内容渲染时间，贴近用户感知。但缺点是无原生 API 支持，算法推导时 DOM 节点不含权重。
# 怎样采集正确的数据？
上报页⾯加载开始时间，以及后续各时间点相对增量，在数据端进行阶段清洗和异常处理。
# 上报关联的维度
我们都知道在做前端的数据采集的时候，维度数据是非常重要的，除了我们刚才定义的各种度量，怎样采集到合适的相关维度，也能够极大地帮助我们分析页面性能的效果。
在分析页面性能的时候，有很多相对专业的维度是会被大家忽略掉的，比如说当前页面是否可见，这个页面加载方式是怎么样的，它是直接打开，还是刷新打开，还是前进后退打开等等。就是通过后面的数据分析，我们会发现，不同的页面操作，页面打开方式都会对我们页面加载的性能会有影响，以及一些更复杂的，比如说是否启用 HTTP2、Service Worker 等等，这些数据我们都应该尽可能采集到，从而能够更好的去分析我们的页面性能。
# 原文
本文为蚂蚁金服如何把前端性能监控做到极致? 的阅读笔记。
拓展阅读 我理解的前端性能 & 优化